Simple video communication platform

ABSTRACT

A system offering simplified bi-directional video communication between a user and a device of a pre-configured one or more persons of interest includes a touch display with a pictorial representation of each of the one or more persons of interest and a pictorial representation of one or more health indicators. The touch display is configured to establish the bi-directional video communication with a selected one of said persons of interest in response to a single touch of the pictorial representation of the selected one of the persons of interest. In one implementation, the system includes one or more biometric telemetry devices for acquiring and transmitting biometric data associated with a specific health indicator to the touch display, which is then transmitted to a database, processed and accessed by one or more authorized persons. In another implementation, the system includes a workflow engine for healthcare management of the patient.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.16/119,741 filed Aug. 31, 2018, now allowed, which is acontinuation-in-part of U.S. patent application Ser. No. 15/288,963filed Oct. 7, 2016, now abandoned, which is a continuation of U.S.patent application Ser. No. 14/670,512 filed Mar. 27, 2015, now U.S.Pat. No. 9,491,206, which claims the benefit of U.S. ProvisionalApplication No. 62/051,036, filed Sep. 16, 2014, U.S. ProvisionalApplication No. 62/037,731, filed Aug. 15, 2014 and U.S. ProvisionalApplication No. 61/971,929, filed Mar. 28, 2014, each of which is herebyincorporated by reference herein in its entirety.

FIELD OF THE INVENTION

The present disclosure relates to video communication, and in particularto a simple station enabling video communication and telemetryinformation gathering.

BACKGROUND

Seniors and people with special needs often face problems related todepression and health issues due to stress and social isolation. Many ofthese peoples live alone in a special care residence or at home. Oftenthe fact that they are remote from family members leads to healthissues. Overtime people lose interest to social activities, are gettingsocially disconnected, and get into a mode of expectation of familymembers showing up to visit them. This situation of social isolationleads to depression. There is a need to improve their communication withone or more POI (e.g. family member, friend, health care provider,residence staff).

Many families have a member at home that required continuousprofessional health care support. Often the professionals are remote andneed to visit family required time. There is a need for a virtual remotecare support to reduce health care cost while providing a moreresponsive service to patient in remote home. There is a need for asimple video communication system that works seamlessly across differentdevices and operating systems.

Furthermore, a workflow automation engine (i.e. “workflow engine”) isusually used in business automation. For example, a workflow engine canautomate processes such as sending emails or setting up web forms to befilled out. Such workflow engines are geared to very specific use cases.There have been workflows built-into healthcare information managementapplications for a variety of diseases. However, each new workflow ishand-integrated, while clients can only access pre-existing workflows.There is a need for a workflow engine for healthcare informationmanagement that provides workflows that can be updated for specificorganizations in real-time without the need to update any applications.Such a workflow engine should be flexible enough to support any protocolinvolving collecting data from people, reacting to the collected data,and notifying others about data.

BRIEF SUMMARY

In accordance with one embodiment, a system offering one-touchbi-directional video communication between a user of a device and apre-configured one or more persons of interest, and providing healthinformation of the user to one or more persons of interest authorized toaccess the health information, said system comprising: a touch displaywith a pictorial representation of each of the one or more persons ofinterest and a pictorial representation of one or more healthindicators; one or more biometric telemetry devices, each biometrictelemetry device used for acquiring and transmitting biometric dataassociated with a specific health indicator to the touch display;wherein: said touch display is configured to establish saidbi-directional video communication with a selected one of said personsof interest in response to a single touch of the pictorial representedof said selected one of said persons of interest, each biometric deviceis in two-way communication with said touch display; said touch displaytransmits said biometric data to a database for processing; saidprocessed biometric data is accessed by the one or more persons ofinterest authorized to access the health information of the user.

In accordance with another embodiment, a system for managing healthcareof a patient, the system comprising: a system software application; acloud server; a database; a plurality of healthcare workflowdefinitions; a forms engine; a workflow runtime module; and a taskscheduler, wherein: the system software application is in communicationwith the cloud server, the cloud server is in communication with thedatabase that stores the plurality of healthcare workflow definitions;the application retrieves the plurality of workflow definitions via thecloud server, a healthcare professional selects a workflow from theplurality of workflow definitions and completes a form generated by theforms engine; data in the form is submitted to the workflow runtime viathe cloud server; the workflow runtime loads logic from the workflowdefinition to execute a next step in the workflow by and issues a firstcommand to the cloud server to either: a) send one or more action itemsto one or more actors in the workflow via the application; or b)communicate with the task scheduler to create one or more tasks to beprocessed at a later time; and wherein the workflow runtime communicatesa second command to the server to update healthcare information of thepatient in the database.

In accordance with another embodiment, a workflow engine for healthcareinformation management, the workflow engine comprising: a systemsoftware application in communication with a cloud server; a pluralityof workflow definitions stored in a database; a forms engine forgenerating a form in relation to the workflow definitions; a workflowruntime for executing logic in the workflow definition; and a schedulermodule to create tasks, wherein: the server conveys the plurality ofworkflow definitions to the application; a person of interest selects aworkflow from the plurality of workflow definitions and completes theform which is conveyed to the workflow runtime via the server; data fromthe form is communicated to the workflow runtime via the server; and theworkflow runtime issues a first command to the cloud server to either:a) send one or more action items to one or more actors in the workflowvia the application; or b) communicate with a task scheduler to createone or more tasks to be processed at a later time; and wherein theworkflow runtime communicates a second command to the server to updatehealthcare information of the patient in the database.

The foregoing and additional aspects and embodiments of the presentdisclosure will be apparent to those of ordinary skill in the art inview of the detailed description of various embodiments and/or aspects,which is made with reference to the drawings, a brief description ofwhich is provided next.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other advantages of the disclosure will becomeapparent upon reading the following detailed description and uponreference to the drawings.

FIG. 1 is a high level diagram of the components of the system.

FIG. 2 is an example of the application structure.

FIG. 3 is an example of an SVS screen.

FIG. 4 depicts an example of the modules used to deploy simplepoint-to-point video where multiple applications are distributed on oneor more servers.

FIG. 5 provides an overview of the call flow between 2 clients.

FIG. 6 is an example of a Single Page Application (SPA) approach usedfor the smartphone, hub and simple video device.

FIG. 7 shows how a signaling library is used to establish peer to peerconnection between users.

FIG. 8 shows an example of the state machine for establishing a peer topeer call between devices for the SVS system.

FIG. 9 shows an example of a call is being made between 2 devices.

FIG. 10 shows an example process for a device to receive a call fromanother user.

FIG. 11 describes the process of setting up RTC adapter in desktopbrowser.

FIG. 12 describes the process from the application running on a desktopand receiving call information from another device.

FIG. 13 illustrates an overall architecture of an embodiment of a systemfor collecting, storing, manipulating and disseminating biometrictelemetry data collected from a user.

FIG. 14 illustrates a master workflow of an embodiment of a system forcollecting, storing, manipulating and disseminating biometric telemetrydata collected from a user.

FIG. 15 illustrates an embodiment of a system for collecting, storing,manipulating and disseminating biometric telemetry data collected from auser, as displayed on an SVS screen.

FIG. 16 illustrates further details of the embodiment shown in FIG. 15.

FIG. 17 illustrates further details of the embodiment shown in FIG. 16.

FIG. 18 illustrates a detailed workflow for steps regarding acquiringthe biometric data in an embodiment of a system for collecting, storing,manipulating and disseminating biometric telemetry data collected from auser.

FIG. 19 illustrates a workflow for communication with a step countdevice in an embodiment of a system for collecting, storing,manipulating and disseminating biometric telemetry data collected from auser.

FIG. 20 illustrates a detailed workflow for sending an update of thebiometric data to the POIs authorized to access the biometric data in anembodiment of a system for collecting, storing, manipulating anddisseminating biometric telemetry data collected from a user.

FIG. 21 illustrates a detailed workflow from the perspective of a POI inrelation to the workflow of FIG. 20.

FIG. 22 illustrates a system architecture of an embodiment of a workflowengine for healthcare information management.

FIG. 23 illustrates a flowchart for creating/starting a workflow in anembodiment of a workflow engine for healthcare information management.

FIG. 24 illustrates a flowchart for starting an action in an embodimentof a workflow engine for healthcare information management.

FIG. 25 illustrates a flowchart for viewing a history in an embodimentof a workflow engine for healthcare information management.

FIG. 26 illustrates a flowchart for scheduling a task in an embodimentof a workflow engine for healthcare information management.

FIGS. 27-31 illustrate steps for managing a pain medication regimen fora patient in an embodiment of a workflow engine for healthcareinformation management.

While the present disclosure is susceptible to various modifications andalternative forms, specific embodiments or implementations have beenshown by way of example in the drawings and will be described in detailherein. It should be understood, however, that the disclosure is notintended to be limited to the particular forms disclosed. Rather, thedisclosure is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of an invention as defined by theappended claims.

DETAILED DESCRIPTION

A first embodiment, a Simple Video Station (SVS) is provided to seniorsand people with special needs (referred to herein generically as“users”). The SVS has minimal user interaction capabilities other thanallowing to establish video/voice communication with pre-determined POI(POI). Transparently, the SVS can optionally perform several otherfunctions such as monitoring health information provided by biomedicaltelemetry systems or detecting emergency situation like fall orinactivity detection. The SVS also provide the user with medicationreminders, emergency call, and other basic function.

The SVS is designed for users with limited mobility, minimal technicalknowledge and possibly limited by cognitive impairment.

FIG. 1 gives an overview of the solution connectivity. One or more SVS100 users can communicate with one or more predetermined POI 101. Asoftware communication platform for biomedical telemetry and any othertelemetry, which is managed by an integrated cloud computing solutionfor data analytics.

The SVS 100 allows a user to establish for video/audio connection with asingle tap on a picture, corresponding to a POI 101. The POI 101receives the call using an application on a smartphone or tablet 140 oron a computer 150. The SVS also has optional radio support for Zigbee®,Bluetooth® and WIFI® allowing connection to Internet over the air and totelemetry devices using Bluetooth® and Zigbee®. The SVS and applicationsare configured via a configuration database 125. The SVS connects totelemetry 130 devices surrounding the user which allow continuoustransfer of data related to the user and/or the environment where theuser lives via a telemetry database 120 to different applications. Acentral or distributed server 160 may also be used for configuration andmonitoring of one or more SVS that are deployed. The configuration 125and telemetry database 120 may be on the same file system. They may alsobe part of the server 160.

The data is transferred to a database 120 via a network 110, and isstored for analysis such as trending, data mining, and analytics.Notification, alarm, or recommendation can be provided to the POI basedon the analysis. With that information, a POI can decide if an action isrequired or if everything is normal. Similar information is alsoavailable to family members which allow the families to be aware andassured of condition of relative. Assuming an abnormal situation, thesystem can notify a POI for immediate action and prevent undesiredsituation. If a doctor needs to be consulted, the SVS allow video/audioconnection to a POI enabling the user to have a discussion on thesituation without having to move outside of their apartment. The SVSallows three-way conferences with any POI, for example, a healthprofessional, a family member, and a user.

The SVS can optionally have sensors (e.g. Near Field Communication tokenreader) to record when visits are done by a POI to the user. Thisinformation is maintained in a database. The profile of the POI mayoptionally be loaded on the SVS when they are visiting allowing themaccess to their contacts. Optionally, any POI can load their profile onthe SVS in order to access their contacts and make call. The profileloading could be made by, for example, a pre-determine gesture on thePOI's picture of the SVS. The SVS can optionally be used in kiosk mode,whereby the SVS is loaded with a profile (POI or USER) when anidentification token is detected by a sensor. The profile is removedwhen the person walks away from the SVS.

The SVS incorporates touch screen technology, displays a set of fixedand predefined pictures on which a simple touch enables a video/audioconnection to the desired POI The intent is to connect families in avery easy way and to address some of the social isolation issue forusers. The SVS also enables virtual care and helps to limit health careprofessional visits saving time and money while offering more responsiveservice. The SVS is also a reference point for time, date, season, andreminder on health recommendation like time for drugs, and time forspecial treatment. The SVS is also transparently to the user a bridgefor the telemetry and sensors technology. The data gathered from theSVS, is analyzed and acted on when needed to secure the environment. TheSVS also comes with profile setting to enable more flexibility inconfiguration. In this case, a list of pictures can be used, withswiping to navigate, and on screen keyboard search. With a more flexibleprofile, the SVS allows instant message and emotions to be sent betweena user and the POI.

The SVS generally comprises:

Touch Screen

Speakers

Microphone

WebCam

Ethernet connection

Radio: Zigbee®, Bluetooth®, WIFI®

Stand to support the SVS or wall mounted [0038] Optional output port toconnect to larger screen TV [0039] Optional audio jack to connect toearphones.

The SVS is remote configuration by an admin including the selection aprofile between full flexibility (for more experienced users) or simpleexperience (for the user).

In Simple experience profile, the limited functions available comprise:

i. Selection of the POI to be displayed as people to be called

ii. User login for the SVS (this map to the person using the SVS)

iii. Pairing of the telemetry devices or sensors

iv. Adjustment of date, time, and season

v. Desire selection of display for availability

vi. Time for emotion text to be displayed

vii. Auto detection of faces with camera movement

viii. Auto detection of voice alert

ix. Auto detection of emergency call on SVS

x. Configuration of emergency call (911 or health care staff)

xi. Auto answer video/audio on call

xii. Auto video/audio on emergency call

xiii. Auto alert to specific user on emergency call

xiv. Auto alert on certain biomedical/vital signs

xv. Enable recording of video/voice message

xvi. Language setup

xvii. Configuration of temperature units

In full flexibility profile (All the above and the following):

xviii. All POI listed for a user are displayed and swapping is used tonavigate

xix. Enable keyboard access for Instant messaging & Emotions

xx. Voice recording for message

xxi. Continuous picture gallery display

xxii. Internet browsing

xxiii. Music players

xxiv. Games support

xxv. Instant video clip playing

In simple profile, the SVS displays the pictures of the POI configuredand allow selection for call. If a POI is not available, the photo isgrayed out or disabled as shown in FIG. 3. If available, the photo is inrelief and looks like a button that can be pressed. The photo also hasthe name of the person on it.

The SVS also allows for a POI to send emotion message to be displayed onSVS. A POI can optionally send a text or instant message that getsdisplayed on the picture for a configurable time. In the simpleexperience profile, the SVS doesn't allow for a reply to make it simpleon users. In the full flexible profile, the Instant message & emotioncan be sent from the SVS.

The SVS allows for call scheduling. The POI using the application canoptionally schedule a video call with a user. At the scheduled time, analarm is emitted on the SVS to notify the user that a call is about tohappen.

The SVS also has voice recognition to allow connection through voicecommand. A user can initiate a connection by talking and mentioning thePOI to be called or to place an emergency call.

The SVS always ensures a voice-only connection if bandwidth for video isnot sufficient. The SVS has a Webcam that allow video capture andtransmission. The webcam preferably recognizes facial movement andadjusts based on the position of the user.

Emergency call (911 or staff call) is placed if screen is consistentlytouched for a predetermined time. On an emergency call and ifconfigured, the video turns on automatically. On an emergency, a list ofdesired POI can be notified of the situation. An alert can be sent toeach of them.

The SVS has recognizes if a user has touched several times in fewseconds a picture. This can be considered as a single touch. This allowsfor users with agility problem to use the systems (Parkinson is anexample) effectively.

The SVS, on connection, displays the person been called in a qualitysize. Another touch on the end call button or the picture ends the call.

The SVS may be integrated with a fall/inactivity detection bracelet andcalls an emergency automatically on fall detection or inactivitydetection or simply when an emergency button press on the bracelet. TheSVS generates warning and then alarm on the inactivity situation.

The SVS calls an emergency number automatically on vital signs alarm.Example, on a pulse change going lower than expected, the SVS calls anemergency number based on configuration.

The SVS also provides one or more reminders to the user. The remindercan be programmed remotely by a POI. Reminders can be scheduled in thefuture and optionally recurring. Reminders can be social activities,drugs and appointment.

The SVS can also support marketing message to provide the user withinformation on the product of its interest.

The SVS provides the user with reminder on the telemetry maintenance ifrequired (e.g. low battery).

The SVS can receive video call and rings like a phone until it is answeror the caller hang-up. Display show the person calling in larger formwith “Call received.” The SVS answers. The SVS has the capability torecord a video/audio message if enable and if phone not answer. The SVShas the capability to record a video/audio communication on a one touchon a record button while in a call. An animation may be played on thescreen to remind the user how to activate the function.

If enabled at configuration time, the SVS displays in bigger form(bigger picture) when the user is near the screen with his finger buthas not selected (touch).

The SVS allow incoming call from a POI even if it is not listed as apicture on the SVS, as long as it is in the list of the users. If not inthe list, the SVS can optionally reject the call.

To avoid getting into complicated states, the SVS has a special approachto get into configuration mode. Touching bottom left corner of thescreen for 7 times quickly bring the SVS in configuration mode. Anyother combinations or times can also be used. The power down button canalso optionally be disabled as well, the sleep mode can also optionallybe disabled avoiding cases where the SVS is turned off or in a statethat is difficult for the user to manage. As another embodiment, specialgestures applied to the logo on the screen can enable differentconfiguration modes.

The SVS supports remote debug/diagnostic, if enabled in theconfiguration. The SVS can have a software update remotely. Update canbe scheduled at a preferred time using the configuration menu and istransparent to the user.

Optionally, the SVS keeps track of statistics. The SVS monitors whichPOI is called more often than other. This can be used to change thepicture of the POI used on the SVS dynamically. Access to the log filecan be done through the configuration menu. The SVS tracks the timespent on connection between a user and a POI to have history and trends.

The SVS, if enabled, allows display of the current telemetry on screenin place of some POI pictures.

The server 160 monitors one or more SVS to ensure they are alwaysconnected and in the proper login state. If connection is lost, theserver notifies a POI or a system manager. If the SVS loses the loginstate, it retries automatically for a predetermined number of timesbefore it sends a notification.

Remote control, configuration and updating of the SVS may use encryptedchannels to avoid loss of personal information.

The SVS can optionally automatically answer a call to allow a POI toevaluate the situation by video with a user that is not answering acall.

The user optionally wears a wearable device referred herein as a wristremote control (WRC) to enable remote control capability of the SVS. Acall can be received and answered from the WRC enabling the video SVS toaccept the call. The WRC can optionally be used to receive reminder (thesame reminder that are available on the SVS). The WRC optionally allowsa POI to detect falls based on its sensitive positioning device. The WRCprovides an emergency call link to the SVS for immediate videocapability and emergency call. The WRC optionally allows selection of acontact to call and initiate a call on the video SVS. The WRC optionallyallows reception of a personal message from a POI (e.g. text message).The same message can be displayed on the video SVS. The WRC allow falldetection generating an alarm through the SVS to the POI. The WRC mayalso enable inactivity detection leading to warning and then alarm.

A WRC can optionally be used by the POI to, for example, receiveemergency call and the biomedical data of a user, receive biomedicaltrend data for a user or receive reminder/tasks to be completed.

The user of the SVS can communicate with another SVS or any other mobilephone or computer via an application used by a POI available through anyapplication stores. An application is also available for download on aPC or Mac. FIG. 2 provides an example of applications running oncomputers 150 and smartphone 140 for POI 101. The user may wear atelemetry sensor 170 which communicates transparently with the SVS 100to transmit the telemetry information which is stored in a database 120and retrieved by the POI application 150, 140.

The SVS can be configured into a kiosk mode with a badge reader allowinga user to tag in have its profile loaded. When this is done, the SVS canbe used by different users, for example in a library.

The SVS can optionally be setup into multi-users where a user selectstheir profile and login.

Application

The application is used to communicate between a SVS user and a POI. Theapplication configuration management, through a web portal or on thedevice, comprises:

1. Selection of language

2. Creation/Configuration of the POI

3. Configuration of the POI and user list

4. Upload of picture for the POI

5. Login & password management

6. Creation of one or more group for one or more user for availabilitystatus for each group.

The application presents the POI with a user login screen. After thelogin action, the POI is presented with a list of users and otherpersons of interest with the associate pictures (see FIG. 2). Thepictures are gray out or normal indicating availability or any othercolor combination showing availability. Gray out mean that the user orPOI are NOT available. Beside each user or POI is a connect button, atexting message button, or telemetry button. If telemetry access isenabled, the POI can select the telemetry and see the history andcurrent user data. With the telemetry enabled, the POI can be notifiedof alert if configured in the SVS.

The application allows the user or POI to define availability per user,per group, or for all. This is useful in the case that a user keepscalling back due to memory challenges like Alzheimer. The POI logoff orset is availability status to unavailable if this is necessary. Inanother embodiment, a timer may be configured for each POI and the useris prevented from calling back a POI if they just completed aconversation earlier than the expiry of the timer.

In order for the SVS, or application, to connect between users and POI,a communication server is required. The communication server can be thesame server as the configuration server or a different one. It can becentralized or distributed. A server with all user and POI isprovisioned and refreshed regularly or each time a new user or POI isadded. The concept of “user in the cloud” is used. Anyone using theapplication or the SVS has a user identifier and password and a picture.The profile of the user or POI is stored in a configuration database125.

If a connection needs to be established, the server signals theconnection and sets up a peer to peer direct connection between the userand POI.

Optionally, the data related to telemetry is stored only for a maximumof days of history. Optionally the telemetry database is located onprivate network and secured with encryption.

In order to establish connection between two SVSs or with anapplication, the system needs to go through a signaling process. Aftersignaling completed, the peer to peer video connection is established.Prior to that, a server in the cloud (the configuration server) does themapping from one user to the POI. The user initiating a call has acommunication identification (commID). This commID is pushed to theserver. The users or POI that are logged in all have a unique commID.The signaling handles the connection between the originator of the calland the recipient of that call. When signaling is completed, aconnection gets established, and then a peer to peer connection takesplace with video and audio. The server can be a public (e.g. Google.®server or a private one. The protocol WEBRTC is an example of an opensource software platform that can be used. Any other protocol thatinteroperates between any platforms can be used.

Telemetry/Sensors Platform

The SVS is designed to enable connectivity with telemetry equipment andsensors that can communicate through Zigbee® or Bluetooth®. Any wearableBiomedical devices or any in room telemetry or sensors equipment thatcomply to the API of an open platform, can be connected to the SVS andhave the data transferred to the user database and be stored/analyzed byqualify staff The remote configuration of the video SVS, allowsadministrator to add protocol compliant telemetry or sensors equipment.

The SVS has alarm detection, which flags issues with telemetry data asconfigured to one or more POI. With the telemetry data transferred tothe network, POI can review to identify anomalies. The system can alsobe configured to notify POI of unexpected behaviors. As example, anirregular pulse can trigger an alarm. Another example is an element openon a cook top for long time can trigger an alarm if some telemetry is inplace for monitoring such event.

The telemetry data is transferred on a continuous basis while the useris collocated with the telemetry sensor and the SVS. When outside ofreach, the telemetry sensor may buffer the data in memory until the nextavailable time of connectivity with the SVS.

The SVS, with the telemetry information, may report to POI the mood of aperson. Using heart rate, temperature trends, and potentially bodyhumidity level, the system indicate to the POI how the user is doing andif the person is suitable for a call in the case where the person may belimited by cognitive impairment. The feature helps with ensuring that acall is made to a user when in its best condition. The POI is optionallynotified by a red, yellow, or green status light on the application.

The SVS is pushing continuously data to a server and database forstorage and analytics. The server can analyze trends per user for eachtelemetry items and based on notification configuration, notified POI ifundesired situation happen. The server can also do some data mining,some pattern analysis, and provide with potential warning of humanchanges or environment change. The data trending, mining observation,and notification are store in the database and can be accessed by POI toanalyze and provide recommendation to a user.

Since the data is per user, it is possible to configure that one or morePOI, access at the data. Family can maintain a close status on users.The data is useful for health staff like doctors to see trends andbehaviors to diagnose a situation.

The servers and database can be implemented as a standalone system for aresidence or cloud services where the servers and databases are offeredremotely as a service to the residence. A residence may decide to have aserver infrastructure local and have the data private while thecommunication is still possible.

Since it is also important for residence management to monitor staffinteraction with resident (user) and to ensure that face to face serviceis offer, telemetry/sensor are used to monitor visits to each apartment.The badge reader or identification card can connect to the SVS and pushinformation on visit time and staff identification. This way informationper staff and per user is available to management to improve its serviceif required. It is also extremely useful for audit as the data isavailable and reports can be issue with the administrative application.

An administrative application is available to selected POI.

From the administrative application, several functions are available:

a) Administrator: This professional can add or delete user or people ofinterest. It can enable debugging, or network performance monitoring. Itcan configure databases and servers. He can set privilege for otheruser. It has access to all system data. The admin can also configure aSVS and force a reset of configuration of a SVS.

b) Health Specialist: This professional has access to all user data andcan use trending, data mining, history, and current data. Thisprofessional can set new threshold or alarms for a given user. Thisprofessional can set the reminders and the schedule of the reminders.This professional can request from administrator a reset of the data.

c) Management: This professional has access to statistics, and report onuser interaction but does not have access to the private data except ifallowed by a user and the health specialist. This professional hasaccess to all staff data and interaction with resident. He can setnotification alarms for staff scheduled visits with resident and ensurethat they are done. This professional can print report for auditpurposes.

d) Staff Support: This professional provides assistance to the user tosetup the telemetry. They have access to server to ensure that telemetrydata is active. This professional also received telemetry alarms likebattery low, malfunction, and can take action to repair telemetry. Thisprofessional also gets alarms on environment telemetry like waterleakage or cook top open. In this case, the professional can takeimmediate action. This professional can add user or person on interestremotely. A SVS can be programmed remotely with the expectedconfiguration and list of POI. Typically this professional helps insetting up the SVS after the sales of the service.

The administration application allows to input manual data by hand tothe database for each user. For example, data from a visit can be storedper user based. This data can be used by health specialist and can bereport on.

FIG. 4 depicts an example of the modules used to deploy simplepoint-to-point video where multiple applications are distributed on oneor more servers. The embodiment includes a document oriented databaseand a key value store (type NOSQL) 403, an authentication server tocontrol access 404, a Message Queue Telemetry Transport (MQTT) brokerserver 405 used for messaging between processes for websockets andTCP/IP sockets.

The HyperText Transfer Protocol (HTTP) module 401 enables HTTP requestto get contact list, device setting, and information on contactinvitation for the SVS. All device type could emit an HTTP request toget information from the server.

The MTTQ service broker 402 provides SVS with an Application ProgrammingInterface (API) that enables desktop applications or IOS applicationsand SVS station to send/receive MQTT messages to/from other devices inthe network. The API is a custom broker built with an open sourcelibrary. The broker 402 also performs authorization and request forauthentication.

The MQTT Android service broker 406 provides SVS with an API thatenables Android app to send/receive MQTT messages to/from other devicesin the network. The API is a custom broker built with an open sourcelibrary. The broker also performs authorization and request forauthentication.

The database 403 enables the SVS platform with a document and graph typedatabase (NoSQL). The database maintains all administration informationabout the users, status, preferences for the system, preference of typeof call, contact list, pictures, voice mail, video messages, logs onusers about health.

The authentication server 404 provides a server mechanism toauthenticate any access to data. It is used for MQTT message and HTTPrequest. Any failure to comply causes an error of authentication anddata is not accessible.

The MTTQ broker 405 is an open source library. This container ofsoftware enables messages to be created, delivered, and diagnosed. TheWeb Socket and TCP brokers are communicating with the MQTT broker formessages.

FIG. 5 provides an overview of the call flow between 2 clients. The buzzlibrary enables signaling between the clients using the MQTT transportlayer. Messages are exchanged until protocol agreement. RTC is then usedover the Internet Communication Engine (ICE) framework to establish thepeer to peer (P2P) connection path. When done, the client communicatesover P2P. Session Traversal Utilities for Network address translation(STUN) and Traversal Using Relays for Network address translation (TURN)servers are used into the P2P connection to overcome firewalls androuting issues.

A device 501 of a user establishes a peer to peer video audio call. TheSVS application running on the device presents an interface to the userto make its call and interact with the signaling engine library throughthe SVS public API. On user request, like pressing on a call button, theSVS device application executes the proper algorithm and call APIs ofthe signaling library to start the process of a call.

The SVS application running on an user device, include the signalinglibrary 502 which enables the application to signal the far end devicethrough MQTT messages to setup a connection. The signaling library 502algorithm takes care of identifying the room ID for the communication,gets authorization to communicate from the servers, prepares theadequate MQTT message with the ID of the callee, and sends the requiredmessages. The signaling also takes care of the reception of a requestfor a call. The signaling library 502 acknowledges a request. Finally,the library 502 also exchange on the Session Description Protocol (SDP)and the ICE candidate to be used for the communication between the 2users. Any message been sent from the library is sent on the cloud(Internet) with the proper destination address. After the signalingphase is completed and that the room could be joined by both user'sdevice, the signaling library proceed with establishing a peer to peerdirect connection by using the “Peer Connection Adapter” represented inFIG. 5.3.

The PeerConnection Adapter 503 provides the SVS system with anabstraction layer of the WEBRTC primitives. The simple API enables thesignaling library to establish, or close calls very easily. When acommunication is established between 2 devices, the ICE candidateestablishes the direct P2P streaming via WEBRTC. It also enables errorhandling and fault detection. The adapter is not available for IOSdevices.

The STUN and TURN component 504 of the SVS systems handles discovery ofIP address behind firewalls and routers. The STUN is a standardized setof methods and a network protocol to allow and end host to discover itspublic IP address if it is located behind a network address translator.TURN is a protocol that assists in traversal of NAT or firewalls formultimedia application. Adding this component 504 into the SVS systemensures that an IP is known and reachable.

The SVS system may comprise an RTC Adapter for iphone Operating System(IOS®) 505. This adapter provides equivalent function of thePeerConnection adapter 503 for Android and PC. This abstraction layerprovides access to the WEBRTC primitive on IOS. The RTC phone adapteralso provides an API that enables the signaling library to establish, orclose calls. When a communication is established between 2 devices, theICE candidate is set and used to establish the direct P2P streaming viaWEBRTC. It also enables error handling and fault detection. The adapteris only available for IOS devices

An IOS signaling library 506 is used for IOS connections.

Devices communicate over the internet 508 for their private P2Pvideo/audio call.

Referring to FIG. 6, a Single Page Application (SPA) approach is usedfor the smartphone, hub and simple video device. For mobile Android orthe simple video device, a Crosswalk wrapper is used. For IOS devices,another RTC platform is used, and for the desktop, a Node webkit is usedalong with a launcher page.

A Single WEB Page Application (SPA) 601 for the mobile device is used tocreate mobile content using, for example, the Crosswalk wrapper for theAndroid devices. Support for HTML5, CCS3, Javascript is available.

The crosswalk wrapper 602 is a simple implementation of a Crosswalklibrary for the SVS systems for the android devices. It enables theapplication to run, for example, HTML5, Javascript, and CCS3.

The SPA is executed on a mobile device 603.

For desktop, a Single WEB Page Application (SPA) for Desktop device (MACand PC) 604 is provided. The web content is created using the NodeJSwebkit. Support for HTML5, CCS3, Javascript is available.

The launcher of Single Web Page Application 605 checks if newcontent/new version is available from the content server and refreshwith the latest at start time of the application.

A public source code such as NW.js 606 enables to develop fast, scalablenetwork application like SVS. This platform builds on Chrome'sjavascript runtime. Any other platform with similar functionality can beused.

A desktop launcher 607 launches the execution of the SPA on the PC orMAC.

For the SVS 608, a Simple WEB Page Application (SPA) is created usingthe Crosswalk wrapper 609 for the Simple Video device. Support forHTML5, CCS3, Javascript is available. The SPA is executed on a videodevice 610 with optionally reduced capabilities.

In FIG. 7, a signaling library 701 used to establish peer to peerconnection between users. Its public API enables the application 709 tomanage calls between remote device and itself The library has aninternal API 703, a public API 702 and has an RTC adapter 704facilitating the use of RTC 706 for P2P 705. The library uses MQTTevents 707 for discovery of actions to be taken and uses services 708 tosend messages, get authorization and authentication, and to send HTTPrequests.

The signaling Library container 701. The library has a public API usedby the applications, an internal set of API, and provides an RTC adapterto connect to RTC PeerConnection for IOS and PC or to RTC adapter forIOS.

The Public API 702 is used by the application to establish a call with auser on a different device. The Internal API 703 is used by thesignaling library. This is only used internally.

The RTC adapter 704 of the signaling library creates an abstraction tothe specific RTC layer for each device.

The signaling library 701 registers to listen to events that happen withthe delivery MQTT messages 707. When a message is delivered, MQTT eventsare raised to enable the signaling library to take action.

The signaling library is taking advantage of several services 708offered. The service for authentication or authorization is provided tothe signaling library. Service of registration and database access isalso available. Any other services may be offered to the signalinglibrary.

FIG. 8 shows an example of the state machine for establishing a peer topeer call between devices for the SVS system. Five states are enablingthe SVS system devices to take the proper actions. Many of the statetransition are due to MQTT message exchange between two devices based onthe action of the user.

The initial state 801 of the application on a device is the “Idle”state. In this state, no call has been initiated and calls could bereceived or made.

The “calling” state 802 of the application represents that a user on aspecific device using the SPA has trigger a call by pressing the callfunction. The API make_call( ) will transition from “Idle” state to“Calling” state and the proper MQTT message to be sent to the far end.If the user select the hang-up call function or an error happens or thefar end user denies the call, the state machine for this device returnsto “Idle” state. If the far end user accepts the call, the process ofsignaling starts and the SVS device transitions to “Connecting” state.

The “receiving” state 803 of the application represents a user receivinga call on its device from a remote user. The application moves to thisstate based on a MQTT message received. If the application is in idlestate and a “call” message arrived, the state machine moves to“receiving” state. While in “receiving” state, if the user accept thecall, the application for the moves to “connecting” state. In the casethat the call is deny by the user the state moves to “Idle.” If the farend user stop calling (hangup) than the state moves to “Idle.” If theuser receiving the call, answer the call from a different device, thecurrent device SVS state moves to “Idle.” Finally error message onconnecting moves back to “Idle”.

The “connecting” state 804 for the represent the period in time wherethe connection is getting establish. The signaling is getting done andthe WEBRTC peer to peer is getting setup. Assuming a successfulconnection, and the video stream is available, the SVS system moves to“in_call” state. If an error happen while connecting or if one of theuser hangup, the state moves back to “Idle”.

The “in_call” state 805 is the desired state for ensuring that a call isin progress and the application is connected in VIDEO/AUDIO with anotheruser. If any of the user hang-up, or if connection failed, the SVS statemoves back to “Idle”.

FIG. 9 shows an example of a call is being made between 2 devices. Thefirst step is done is to clean the current state 901 of the statemachine to make sure that the previous call's data has been freed frommemory. When this is completed, the state is set to “calling” 902.

After the cleaning activity has been completed, the process will proceedon creating a new communication “Room” 903 by calling a server API. Thenit starts listening on MQTT events related to the room and to thecallee. The MQTT messages are as followed 905:

room=api.calls.call(userid);

MQTT on(r/:room/accept) handle_accept

MQTT on(r/:room/deny) handle_deny

MQTT on(r/:room/hangup) handle_hangup

MQTT on(r/:room/callee/SDP) handle_remote_sdp

MQTT on(r/:room/callee/ICE) handle_remote_ice

MQTT on(r/:room/callee/ready) handle_ready

The SVS system sends an MQTT message to the callee 903 with the roominformation and who the call is from. The form of the message is MQTTpublish: u:/who/call (room).

The SVS system handles calls to be denied 910. If a callee denies thecall, the state is set to Idle 912 for the caller, the state is cleaned914, and the rest of the applications receive a deny event 916.

The SVS system accepts the call 920 by setting the state is set to“connecting” 922 and the RTC connections is setup 924. The room getnotified that the caller is ready for sending RTC information 926 by“emit function” 928: MQTT publish: r/:room/caller/ready 929.

A new RTC adapter is created 930 and set to be initiator of the call.Listeners are added for various events from the adapter. The RTCmessages are: [0173] rtc=RTC adapter instance [0174] rtc on(ice)handle_local_ice [0175] rtc on(sdp) handle_local_sdp [0176] rtcon(stream) emit(“stream”) [0177] rtc on(error) emit(“error”) [0178] rtcon(close) emit(“close”).

FIG. 10 demonstrates the process for a device to receive a call fromanother user.

When the application on a device of the SVS system first boot, itsubscribes the MQTT topic for incoming calls 1001. Once data ispublished to that topic, it is processed as a new incoming call 1003.

The application on the device is listening for calls 1001. Whenever anew call arrives 1002, the application checks to see if it is currentlyin the idle state 1005. If the state of the device is not in the “Idle”state 1007 when a call is received, then the call gets denied and thecaller gets a message over MQTT informing that the call is rejected1009.

If the state of the device is in “Idle” state when a call is received,the state get set to “receiving” 1010 and the user get prompted 1012 toaccept 1016 or deny the call 1007 through the proper presentation layerof the user interface. If the user denies the call using the SVS system1007, than the same process as above is performed.

If the user accepted the call 1016, then the state is set to“connecting” 1018, the state is cleaned 1020, the RTC adapter is created1022, events for the adapter are listened on 1024, the caller isnotified that the call has been accepted 1026, and the callee emits anevent to the room 1028 saying that they are ready to exchange the RTCcommunication data 1030.

FIG. 11 describes the process of setting up RTC adapter in desktopbrowser.

The desktop application gets the camera/microphone media stream 1104,creates a new RTC instance 1106, and attaches a new PeerConnectioninstance of RTC adapter 1108.

The SVS systems can add listeners 1110 to the PeerConnection to handlereceiving new media stream, ICE candidate, and SDP data. It also handlesclosing and cleaning the RTC adapter 1112.

If RTC adapter has been setup as the initiator of the call 1112, theadapter creates the initial SDP string and sent it to the client 1114.The SDP string of the initiator's machine is created 1116. The SDPstring describes the video/audio formats that are supported (bitrate,resolution, compression etc.). The SDP settings are modified 1118 togive more fine-grained customization of the SDP parameters for furtheroptimization. The local SDP string is set 1120. The SDP string isemitted and sent via MQTT to the callee 1122.

FIG. 12 describes the process from the application running on a desktopand receiving call information from another device. SDP information isreceived 1202 from the other device and it is received over MQTT. If theRTC adapter is the initiator 1204, then it processes the SDP as the“answer” 1206 and set the remote description of the PeerConnection 1208.

If the RTC adapter was not set up as the initiator 1204, then itprocesses the SDP as the “offer” 1210, set the remote description 1212,then generates its SDP answer 1214 and emit the answer to theapplication to be sent over MQTT 1216.

Health Indicator Monitoring

It is in the interest of the user to track his/her health information ina manner which is simple. Non-limiting examples include activity (stepcount), blood sugar, blood oxygen saturation, body temperature, pulseoximetry and heart rate, and weight. Such information (“healthindicators”) may be collected by way of one or more biometric telemetrydevices, or input manually by the user. The results are displayed to theuser on the SVS and may be displayed to the one or more POIs.

In addition, in some jurisdictions, collection, storage anddissemination of such personal health data may be required to abide byprivacy legislations. For example, in some countries, personal biometricdata collected from a device must be stored at a physical location (e.g.datacentres) within that country. The same applies to data collectedmanually. In situations where privacy legislation is in place, the datais input directly to the SVS and then transmitted to the database 120via network 110 (shown in FIG. 1). In these instances, the biometrictelemetry devices comprise means for a wireless communication standard(e.g. Bluetooth®, Zigbee®, or any other wireless communication standardknow in the art) with an open interface.

Alternatively, where such legislation is not an issue, the data maytransmitted to a cloud first, and then transmitted, via authentication,via network 110 to database 120.

The SVS is configured to allow for manual input of biometric data, or tointerface with one or more biometric telemetry devices. In order tosimplify the process of taking a reading using the SVS, the useractivates a protocol of the SVS. Such activation may include touching abutton icon on the SVS screen. If a biometric device is to used toprovide data for the health indicator, the SVS application dynamicallydetermines how to communicate with the appropriate device based on knowndevice names. A simple interface is provided for showing visual features(for example, graphs, charts, etc.) of trends for the user's biometricdata. Optionally, a summary of the results can be shown to the user. Forexample, this may include a weekly summary of their daily results; amonthly summary of weekly results, or any other suitable format. Inaddition to accessing the biometric data, the user interface can alsocontrol who in the list of POIs accesses or sees the biometric data.

The biometric data is stored on database 120 for later viewing and/orfor sending real-time updates to one or more active viewers (i.e. POIs)of the data.

The infrastructure for permission management (between POI 101 and thenetwork 110) may be used to control which POI may have access to one ormore of the user's health indicators. As such, each authorized POI isable to see one or more summaries, or updates of a user's healthindicators after the readings have been taken. Alternatively, theauthorized POI may see the readings in real-time, since as soon as theuser takes a health indicator reading, it is pushed to each logged-inPOI that is authorized to see it.

The devices for monitoring of health indicators are distinct from thefall detection bracelet. A few of the key differences are as follows. Amain purpose of the WRC is to continuously monitor users so that peopleimmediately responsible for their care are immediately alerted when anegative event occurs (e.g. a fall). This, for example, would be a POIwithin a facility where the user is located.

As such a user is always wearing the WRC, which is always be turned onand connected to a tablet (e.g. SVS). The user's urgency contacts arenotified if the WRC is disconnected from the tablet (e.g. battery runsout, user wanders away, etc.). A user can press a button on the WRC tocall for help from facility staff; the WRC automatically notifiesfacility staff when the user falls down. Furthermore, within a facility(e.g. a nursing home), tablets may collaborate in order to connect tobracelets for users anywhere in the facility and relay events to thepatient's main tablet. Furthermore, each user has a unique WRC“assigned” to them by saving the bracelet MAC address to their account.A history of falls/urgency calls is not shared with the circle of care(i.e. all of the POIs), but only that POI (i.e. management) which iswithin the facility.

Conversely, the devices used to monitor health indicators are not used(or turned ‘on’) until the patient requests a reading. An exception maybe a step counter, which is usually affixed to the patient and iscontinuously taking step readings. Furthermore, not all of the healthindicator types have device integration—as described below. Data can bemanually entered from non-Bluetooth devices. In addition, a user doesnot need the hardcoded MAC of a device in order to connect to it.Instead of using the multi-tablet scanning approach for fall detectionbracelets, a simply scan for nearby devices with the appropriate name isperformed for monitoring of health indicators. Multiple types of data(e.g. weight, blood oxygen, pulse, etc.) is collected through healthmonitoring. Finally, any number of the POIs can gain permissions toaccess data for a given health indicator and see trends on the data.

FIG. 13 illustrates an overall architecture of a system 1300 forcollecting, storing, manipulating and disseminating biometric telemetrydata collected from a user.

The user 1305 interacts with the application on his/her SVS 1315 (e.g.laptops, desktop computers, tablets, phones, etc.). The application onthe SVS 1315 guides the user 1305 on how to take one or more readingsusing the device 1320. Alternatively, the application on the SVS 1315guides the user on how to enter biometric data manually.

The biometric telemetry data is sent to the SVS 1315, and processed sothat it is presented in an easily-readable form for the user. The datasent is then via the application to the database 1340 (which may bestored in a cloud 1325). One or more of the POIs who is authorized toaccess the health data, can check to see if new health data has beenuploaded to the database. Processing may include conversion to a certainformat; conversion of units, etc. The one or more POIs 1335 each use theapplication 1310 on his/her individual device 1330 (laptop desktopcomputer, tablet, phone, etc.) in order to view data from the user 1305.The one or more POIs 1335 may then address changes in the observedbiometric data by getting in touch with other POIs, the user and/orupdate any medical records of the user 1305.

FIG. 14 illustrates a master workflow for a user taking a reading ofbiometric data, and having the read data sent to selected POIs. Tobegin, a user opens the application on the SVS, and take a biometricreading using an appropriate device. The data is saved to the databaseon the cloud and displayed on user's SVS. In addition, notification ofthe reading is sent to the POIs.

FIG. 15 illustrates an example of an SVS screen with an icon “HealthIndicators” which the user may touch to access information aboutprevious health data and/or take a new reading of one more healthindicators.

For example, when the user touches “Health Indicators”, the SVS displaysan overview of the most recent health data, as shown in FIG. 16.Included in the overview is a list of the most recent health data of theuser. While six health indicators are shown, it is understood that moreor fewer health indicators may be monitored. The screen also providesfurther access to specific health indicators (as shown in the column onthe left), or, back to the main SVS screen (via the button “Back”).

For example, if the user wishes to obtain further information on his/herpulse oximetry and heart rate, s/he can touch the “Pulse Oximetry andHeart Rate” button on the left. By doing so, the user is taken to a newscreen, shown in FIG. 17, which provides more details about his/herpulse oximetry and heart rate. For example, the most current reading isprovided, along with preceding measurements. This can also berepresented in graphical format. The user has the option of entering anew reading manually or reading from a biometric device (to provide anew reading). A similar display is provided for the other healthindictors.

FIG. 18 illustrates a more detailed workflow for steps regardingacquiring the biometric data. A user opens the application on the SVS,and decides on a type of biometric data to read. For example, it may beactivity steps, weight, blood pressure, pulse oximetry, heart rate,level of oxygen in the blood, etc. While four types of biometric dataare shown in FIG. 18, it is understood that other types of health datacan be read (as shown in FIGS. 16 and 17).

Once a type of biometric data is chosen, the user indicates to the SVSthat a new reading is to be taken —either manually or through a device(as shown in FIG. 17). This can be accomplished by pressing either“enter new reading” or “read from device”, as shown in FIG. 17.

If “enter new reading” is chosen, then the user is prompted to input thehealth data manually. On the other hand, if the user opts to use adevice to take a health reading. a device module on the SVS receivesinformation of the type of health reading that will be taken. The modulewill then load information particular to the type of biometric data thatis to be acquired. The SVS may communicate with the biometric deviceusing Bluetooth®, Zigbee® or other similar protocol.

For example, the device module can track the following information: thename of the device to search for; which Bluetooth Low-Energy (BLE)service and characteristic the module should write to in order toinitialize the device in question; which BLE service characteristic itshould read from in order to the particular health indicatorinformation, and what text to display on the SVS at different stepsduring the measurement process.

The module will then prompt the user with a device-specific message toprompt the to prepare the device for taking readings. The biometricdevice can be any suitable device that allows for interfacing usingBluetooth®, Zigbee® or similar protocol known in the art.

The module will then begin scanning for nearby BLE devices and will seeif the device's name matches the device needed to take the reading. Ifan appropriate device is not found within a certain pre-set time frame,the process will “time out” and prompt the user to take another reading.The pre-set time frame may be a few seconds to a few minutes.

If an appropriate device is found, the user will be notified that thereading is taking place and will see a graphical indicator regarding thestage of the measuring process. For example, a progress bar, or similargraphic, can be used, to mark the progress, or state of completion, ofthe reading.

FIG. 19 illustrates a workflow for communication with a step countdevice. The user has indicated that s/he will take a step count readingfrom a biometric device. The SVS scans for devices using Bluetooth®. Ifno device is found within a certain timeframe, the user is prompted toeither retry or end. If a device is found, its information iscommunicated to the SVS which checks to see if the found device is thestep-count device. If it is not, then scanning continues, either untilthe step-count device is found, or the user decides to end the attemptto perform a reading.

Once the device is found, scanning is stopped. The Bluetooth® interfacetries to connect with the step-count device's media access control (MAC)address. Once connected, a message is sent to the user (on the SVS) todo the reading until completed.

Some biometric data requires a single reading, while others require anaverage of readings.

As an example of a health indicator for which a simple reading is used,is a MetaWear® bracelet (from mbientlab) that tracks step counts. Themodule can listen on the BLE characteristic used for the step countreadings. It can then write to a BLE characteristic to start the reading(if necessary). Once the reading event occurs, the module saves thehealth indicator to the database (in the cloud) and displays a “success”message to the user.

An example of a health indicator that requires the calculation of one ormore averages, is the amount of oxygen in the blood. An exemplary deviceis a Nonin® pulse oximeter that measures an amount of oxygen in theblood. For such a reading, the module may start listening on the BLEcharacteristic for the reading. Once a new reading occurs, it's value issaved to memory (i.e. the application memory on the SVS). Once enoughreadings have been collected to perform a reliable average, an averageof the reading is calculated. As with the single reading biometric data,once the average has been obtained, the module saves the healthindicator to the database (in the cloud) and displays a “success”message to the user.

FIG. 20 illustrates a more detailed workflow for sending an update ofthe biometric data to the POIs authorized to access the biometric data.Once the new readings have been sent to the database, an event will begenerated for the MQTT broker, such that the cloud provides an MQTTbroadcast. If a POI is authorized to receive the data (ie. subscribed tothe particular MQTT event), then s/he will receive the biometric data.Thus, privacy is ensured such that only authorized POIs receive medicaldata.

This is further detailed in FIG. 21, which illustrates a perspectivefrom a POI. When a new reading is uploaded to the cloud, each POI doesnot get a push notification. Instead, his/her application receives anevent with the updated data only if they are currently viewing the data(via MQTT). The POI may then open the application on the device tonavigate to the user's health indicator data. The cloud then checks tomake sure that the POI has permission to access the health indicatordata. If not, then no further information is provided to the POI. Ifyes, then the POI subscribes to the MQTT event (for that particularhealth indicator data) and receives the specific health indicator data,which is then displayed on the POIs device via the application. Such adisplay may include trend of the data for a completed period of time(e.g. a few days, a week, two weeks, a month, etc.). In addition, thedisplay may include a summary of the last few readings for thatparticular health indicator.

If the POI is in communication with the user, while the user is takingbiometric data readings, and the POI is authorized to receive the data,then the MQTT event will enable the application on the POI's device todisplay the new data immediately (i.e. dynamically).

Workflow Engine for Healthcare Information Management

The workflow engine for healthcare information management disclosedherein differs from current such workflow engines by providing a dynamicplatform: workflows can be updated for specific organizations inreal-time without the need to update any applications. A workflow enginefor healthcare information management disclosed herein is flexibleenough to support any protocol involving collecting data from people,reacting to the collected data, and notifying others about data. Theworkflow engine uses high level components that make it easy to addfeatures upon client demand.

The workflow engine has several practical uses. For example, it can beused to: help with medication regimens for post-surgery patients; doremote checkups on patients; and to automatically monitor patients'health.

The workflow engine is embedded into the platform (described above) andrequires the software application described above to function. Workflowsare all patient-centric in that the actors within a workflow include thepatient, and all data collected is tied to the patient's records. Actorsin a workflow are always a subset of a patient's circle of care (orPOI).

An organization is entrusted to manage care of a patient. A workflow isrequired to manage this care. Members of the organization are POIs ofthe patient; this designation is also labeled as “the circle of care”for a patient. These members generate the workflows. To access theworkflow engine, a POI must be given permission by an administrator whensigned on. The POI then logs onto the workflow engine system, navigatesto the patient, and accesses the workflow for that patient. S/he willreceive a list of workflows for the patient. The workflow files areconstructed and digitized by the workflow engine based on theorganization's protocols. The POI will then choose from the list ofworkflows.

First, the system software application is used to communicate with thecloud server in order to fetch a list of workflow definitions from thedatabase. The person interacting with the application will then select aworkflow and use the forms engine to do initial configuration. When theform is “submitted”, the data is sent to the cloud server which willsend the data to the workflow runtime. The workflow runtime will loadlogic from the workflow definition in order to determine what the nextsteps are for the workflow. It will send commands back to the serverwhich will then either send more actions to the applications used byactor within the workflow, or talk to the scheduler module to createtasks that will be processed at a later time, it will also send commandsto the server to update information within the database. All the historyof what happens in a workflow is stored in the database so that it canbe reviewed by the patient's circle of care within the softwareapplication or exported externally for analysis.

FIG. 22 illustrates a system architecture (1) of an embodiment of aworkflow engine for healthcare information management.

The workflow engine comprises: a system application (2), a system cloud(3). a form engine in a system application (2); a workflow runtimecomponent (4) in a system cloud (3), an action scheduler component (6)in the cloud (3); and a system database (7). The system database holds,for example, workflow definitions (8), pending actions/history (9) andongoing workflows (11). In addition, the workflow engine also comprisesa workflow definition file format. Each component is described below.

Forms Engine

The forms engine (in the system application) is used to dynamicallygenerate user interfaces with real time validation logic for forms thatare displayed to actors in the workflow. The forms engine can be used tocapture and view any sort of data. This includes surveys, pictures,health indicators, medication prompts, etc.

The forms engine is also used to integrate with other features insystem, such as taking readings of health indicators (either frombiometric telemetry devices or from data input manually by the user),linking to the user's care plans, and making calls to actors in theworkflow. The forms engine may support multiple languages within asingle form definition in order to deploy the same workflow in multiplelanguages at once.

For example, the form engine can use a JavaScript Object Notification(JSON) schema for validation. It can also be used to describe fields informs for “actions”.

Each “property” in the schema has an “inputType” and a “displayType” forspecifying how it should be displayed for inputting and for viewing. Theform engine takes these schema definitions and generates a userinterface with the appropriate inputs and outputs based on the schemacontents. Schemas are in the JSON file format, so they can be easilyloaded from the system cloud at runtime and allow for the addition andmodification of forms in the application without needing to update theapplication itself. There are other formats that may be used to achievethe same result such as XML, HL7, YAML, Binary encoding, etc.

Workflow Runtime Component

The workflow runtime component is in the system cloud. In order to reactto form submissions, a scripting language is used to decide what to donext after an actor in the workflow completes an action. This languageis used in combination with certain Application Programming Interfaces(APIs) which are used for scheduling new actions and reactions, savinghealth information, and storing pieces of information used for theworkflow logic.

The workflow runtime is integrated as part of the system cloud. It mayuse a JavaScript sandbox which isolates the scripting language from therest of the operating system in order to ensure that scripts cannot doanything malicious. It can specify several JavaScript functions as beingpart of the “runtime” for scripts running as reactions. Furthermore, theruntime may contain a way to: inject the result of the form (as a JSONobject); show actions to certain actors in the workflow; run otherreactions to facilitate code-reuse; and to “schedule” actions orreactions to run at a later date using the CRON format or a Unixtimestamp.

While JavaScript has been used in the example, it is understood thatother scripting languages may also be used. Non-limiting examplesinclude Lua; a meta-language using the same encoding as the rest of theworkflow (e.g. XML); encoding commands using a custom format thatdoesn't use existing programming languages (e.g. creating a new languageor “bytecode”, using an encoding to describe commands).

An embodiment of the workflow engine includes integration of healthcareindicators with the Workflow Runtime and the system cloud. This allowsworkflows to save information about health indicators (for example,hearth rate, blood oxygen level, weight, body temperature, bloodglucose, blood pressure, activity (step count), etc.). Forms using theForm Engine can take readings which will then be passed to workflowreactions in order to make decisions and to save for later use.

An Event broker can be used to relay events across the entire system. Abroker based on a standard called MQTT which is used for “Internet OfThings” technologies may be used. Other event systems can be used.

Action Scheduler Component

The action scheduler component is in the system cloud. This component isused to schedule future events. For example, it can be used to scheduleappointments, availability of actors, reminders, etc. The actionscheduler can use the CRON standard to schedule tasks to run at a latertime.

Workflow Definition File Format

The workflow definition file format describes workflows in amachine-readable way. This is uploaded to the system cloud for anorganization in order to enable the organization to start workflows fortheir patients.

Use of a workflow definition in the workflow engine allows for theexpression of any type of protocol that revolves around a patient andtheir care. The format allows for easy iteration of ideas, as well asallowing updates without requiring changes to the system infrastructure.

The workflow definition file format can be encoded in JSON to make iteasy to parse in different environments and to generate workflow files.In this manner, it is geared to have everything that is needed for aworkflow in a single file to make it easy to share. It also can containsfields for the forms that can be used with the form engine, the actortypes, the reaction scripts, and configuration information.

While JSON encoding is used, it is understood that other types ofencoding may be used in the workflow definition file format.Non-limiting examples include XML encoding, YAML encoding and custom“binary” encoding.

System Application and System Cloud

The system application and the system cloud form the system architecturethat is used for delivering services and interfacing with all users ofthe system.

FIG. 23 illustrates a flowchart for creating/starting a workflow in anembodiment of a workflow engine for healthcare information management.

A description (20) of the workflow is used to create a workflowdefinition file (25), which can be uploaded (30) to the system cloudusing a system dashboard. A POI subsequently opens (35) the softwareapplication to the patient's workflow information (contained in theworkflow definition file). A new workflow is started by selecting (40) aworkflow definition from a list of available workflows for that patient.At this stage, the workflow engine can optionally configure which“actor” labels in the workflow should point to which members of thepatient's circle of care (i.e. POI). Furthermore, the workflow enginecan optionally configure any initial parameters that the workflowrequires to start (dynamically generated from the workflow definition).The workflow starts once the new workflow is sent (45) to the systemdatabase (50). This generates a new “ongoing workflow” item in thedatabase in order to track the workflow state and associate it with thepatient. If the workflow definition has an initial configuration, itwill invoke the specified reaction with the configuration data in orderto allow the workflow to decide how to start. An “Action” will becreated which will record the identification of the actors from theworkflow that should see this action, as well as which reaction shouldbe invoked next.

FIG. 24 illustrates a flowchart (52) for starting an action (54) in anembodiment of a workflow engine for healthcare information management.

All relevant actors in the list of POIs will receive (56) a combinationof a push notification (if they have a mobile device) and an MQTT event(if they have the app open) which will notify them about the new action.Depending on the type of actor, the action will either pop up right away(58) (simplified UI for patients) or be added to a list at the top ofthe homepage and require the item to be accessed (60) (regular UI forPOIs and patients who are familiar with technology).

The action will render (62) the relevant form based on the workflowdefinition using the Forms engine in the software application. Once theactor has filled (64) out the form, and submitted it, a request is sentto the cloud. The submitted data is validated (66) against the schemaand will result in an error if something doesn't match. Otherwise itwill continue by updating (68) the action's information and invoking areaction (70). All actors receive (72) an MQTT event saying this actionhas been completed so that it can be removed from their list. Once thereaction script runs, the resulting commands are validated and thenexecuted one at a time. These commands will result in either the stateof the ongoing workflow to be updated; new actions to be sent orscheduled; other reaction scripts to run or be scheduled to run; healthindicators to get saved; or other relevant actions.

A member of the patient's circle of care (i.e. a POI) can view theworkflow history in the software application. The POI navigates (82) tothe workflow section in the app; and select (84) the workflow for whichthey wish to view the history. The data is fetched (86) from the systemcloud and MQTT events are set up to display any new actions or changesto actions. The schemas for the actions are used with the form engine inorder to render the results.

FIG. 26 illustrates a flowchart for scheduling a task in an embodimentof a workflow engine for healthcare information management. Thescheduler service starts up. It retrieves the list of all scheduledactivities in the system. It parses the schedule for each task anddetermines the timestamp of when it should run. It sets up a timerper-task which will “run” the task at the appropriate time. It will alsolisten on MQTT events in order to add any newly scheduled tasks, and tocancel any tasks that are no longer needed. Depending on the type oftask it will either send an action to the relevant actors in a workflowor run a reaction script. Once the task finishes running, it will beremoved from the task list.

Example: Workflow for Medication Regimen

The workflow engine can manage a medication regiment for a patient. Thesteps are illustrated in FIGS. 27-31 and described below.

In FIG. 27. a POI navigates to patient's “workflow” section and presses“start a new workflow” (100). In FIG. 28, the POI chooses the relevantworkflow from a dropdown menu (105). In FIG. 29, the POI then fills outthe form (110) with the medication names and times (there may be somedefault medications pre-filled). The POI finishes editing the form andpresses “Save” on the form (not shown). This starts the workflow andwill schedule the medications to be shown to the patient. The POI canvisit the history of a workflow (pictured for a different workflow type)to see all the actions that have taken place (and the results), as shownin FIG. 30. The patient receives notification of workflow action(medication prompt) which they will acknowledge by pressing “DONE” asshown in FIG. 31.

Although the algorithms described above including those with referenceto the foregoing flow charts have been described separately, it shouldbe understood that any two or more of the algorithms disclosed hereincan be combined in any combination. Any of the methods, algorithms,implementations, or procedures described herein can includemachine-readable instructions for execution by: (a) a processor, (b) acontroller, and/or (c) any other suitable processing device. Anyalgorithm, software, or method disclosed herein can be embodied insoftware stored on a non-transitory tangible medium such as, forexample, a flash memory, a CD-ROM, a floppy disk, a hard drive, adigital versatile disk (DVD), or other memory devices, but persons ofordinary skill in the art will readily appreciate that the entirealgorithm and/or parts thereof could alternatively be executed by adevice other than a controller and/or embodied in firmware or dedicatedhardware in a well known manner (e.g., it may be implemented by anapplication specific integrated circuit (ASIC), a programmable logicdevice (PLD), a field programmable logic device (FPLD), discrete logic,etc.). Also, some or all of the machine-readable instructionsrepresented in any flowchart depicted herein can be implemented manuallyas opposed to automatically by a controller, processor, or similarcomputing device or machine. Further, although specific algorithms aredescribed with reference to flowcharts depicted herein, persons ofordinary skill in the art will readily appreciate that many othermethods of implementing the example machine readable instructions mayalternatively be used. For example, the order of execution of the blocksmay be changed, and/or some of the blocks described may be changed,eliminated, or combined.

It should be noted that the algorithms illustrated and discussed hereinas having various modules which perform particular functions andinteract with one another. It should be understood that these modulesare merely segregated based on their function for the sake ofdescription and represent computer hardware and/or executable softwarecode which is stored on a computer-readable medium for execution onappropriate computing hardware. The various functions of the differentmodules and units can be combined or segregated as hardware and/orsoftware stored on a non-transitory computer-readable medium as above asmodules in any manner, and can be used separately or in combination.

While particular implementations and applications of the presentdisclosure have been illustrated and described, it is to be understoodthat the present disclosure is not limited to the precise constructionand compositions disclosed herein and that various modifications,changes, and variations can be apparent from the foregoing descriptionswithout departing from the spirit and scope of an invention as definedin the appended claims.

1. A system for managing health information of a user comprising: aone-touch communication device to enable bi-directional videocommunication between said user and one or more persons of interest; oneor more biometric telemetry devices, each biometric telemetry deviceused for acquiring and transmitting biometric data associated with aspecific health indicator of the user to the communication device; saidcommunication device transmits said biometric data to a database forprocessing; said processed biometric data is accessed by the one or morepersons of interest authorized to access the health information of theuser.
 2. The system of claim 1, wherein the user manually inputsbiometric data associated with a particular health indicator.
 3. Thesystem of claim 1, wherein the health indicator is blood pressure,weight, step count, blood oxygen level, or heartrate.
 4. The system ofclaim 2, wherein the particular health indicator is blood glucose level.5. The system of any one of claim 1, wherein during transmission of thebiometric data to the touch display, a graphical representation of thebiometric data is displayed on the touch display.
 6. The system of anyone of claim 1, further comprising a signaling component based onMessage Queue Telemetry Transport (MQTT) protocol, and a videocommunication component based on Real-Time Communication (RTC).
 7. Thesystem of any one of claim 1, further comprising wireless connectivitybetween said touch display and each of the one or more biometricdevices.
 8. The system of claim 7, wherein the wireless connectivity isestablished using one or more of Bluetooth, Zigbee and WIFI.
 9. A methodfor managing health information of a user comprising: enabling abi-directional video communication using a one-touch communicationdevice between said user and one or more persons of interest; acquiringbiometric data associated with a specific health indicator of the user;transmitting said biometric data to the communication device fortransmission to a database for processing; said processed biometric datais accessed by the one or more persons of interest authorized to accessthe health information of the user.
 10. The method of claim 9, furthercomprising inputting manually by the user said biometric data associatedwith a particular health indicator.
 11. The method of claim 9, whereinthe health indicator is blood pressure, weight, step count, blood oxygenlevel, or heartrate.
 12. The method of claim 10, wherein the particularhealth indicator is blood glucose level.
 13. The method of any one ofclaim 9, wherein during transmission of the biometric data to the touchdisplay, a graphical representation of the biometric data is displayedon the touch display.
 14. The method of any one of claim 9, furthercomprising a signaling component based on Message Queue TelemetryTransport (MQTT) protocol, and a video communication component based onReal-Time Communication (RTC).
 15. The method of any one of claim 9,further comprising wireless connectivity between said touch display andeach of the one or more biometric devices.
 16. The method of claim 15,wherein the wireless connectivity is established using one or more ofBluetooth, Zigbee and WIFI.